Frequently, a user desires to perform management functions for a server using a network connection, such as an Ethernet connection. To this extent, a server may include System Management Software (SMS), which includes an agent executing on the server that enables the user to perform management functions over a network (e.g., “in-band management”). Additionally, current servers often include an auxiliary processor and supporting hardware dedicated to managing the server system, frequently referred to as a “service processor” (also “management processor”). The service processor can provide the user with a second communications path for performing management functions (e.g., “out-of-band management”). Examples of how this second communications path could be enabled include a dedicated network interface, a network interface shared with the system, a dedicated serial interface, or a shared serial interface.
The management functionality implemented by both the SMS agent and the service processor may overlap. For example, both may support power control, environmental monitoring, monitoring and reporting of a status for a field replaceable unit (FRU), alerting capabilities, resource throttling, and/or the like. However, the SMS agent may provide some functionality not provided by the service processor and/or the service processor may provide some functionality not provided by the SMS agent. Regardless, a user may desire to use both the service processor and the SMS agent to manage the server.
Since many management functions are potentially disruptive to the tasks and applications executing on the server, the user is typically authenticated before being allowed to access the management functions supported by the SMS agent or the service processor. Currently, the SMS agent utilizes an Application Program Interface (API) provided by a host operating system on the server to authenticate the user, while the service processor maintains its own authentication data (e.g., user accounts and passwords) stored in non-volatile storage for the service processor, which is used to authenticate the user. As a result, a user that desires to utilize both the service processor and the SMS agent must ensure that its authentication data is included on the server as well as on the service processor.
In general, it is desirable to limit the number of different authentication credentials (e.g., user name and password) for a user. As the number of different authentication credentials grows, it becomes more difficult for the user to manage them (e.g., keep them synchronized, if desired, remember different user names/passwords, etc.). This can result in an increase in the administrative costs for the authentication credentials, as well as a security risk that the passwords will be of a reduced complexity. One approach to this situation is to provide a centralized authentication mechanism, such as lightweight directory access protocol (LDAP). However, such a mechanism requires significant additional resources in order to be implemented on a typical service processor as well as supporting infrastructure available in the network.